home *** CD-ROM | disk | FTP | other *** search
- Path: tank.news.pipex.net!pipex!demon!fpfnet.demon.co.uk
- From: rcc@fpfnet.demon.co.uk (Robert Cragie)
- Newsgroups: comp.sys.m68k
- Subject: Re: Bus Error Handler for 68040
- Date: Thu, 01 Feb 1996 22:12:26 GMT
- Organization: FPF Ltd.
- Message-ID: <823212746.11237@fpfnet.demon.co.uk>
- References: <30FFE81F.4110@infinet.com>
- NNTP-Posting-Host: fpfnet.demon.co.uk
- X-NNTP-Posting-Host: fpfnet.demon.co.uk
- X-Newsreader: Forte Free Agent 1.0.82
-
- Paul Swetnam <pswetnam@infinet.com> wrote:
-
- >I am having difficulty writing a bus error handler for a 68040 processor
- >because of the pipeline architecture used by the processor. The bus
- >errors are trapped by my routine, but when I execute an RTE instruction
- >to return from the exception, the processor often tries to re-run the bus
- >access and re-triggers the same error. This results in an infinite loop.
-
- Sometime ago, I wrote a bus error handler for the 68EC030, which may
- well be similar. I tried using the stack fiddling technique (OK on
- 68000), but it didn't work. Browsing the data book revealed that the
- DF (Data Fault re-run) bit of the stacked SSW (Special Statue Word)
- has to be cleared before doing the RTE. The following bit of code
- worked OK. It assumed that d2 was set to a 'magic' value before
- attempting a 'wary' access to detect possibly legitimate bus errors
- due to non-existent VME boards for example.
-
- Buserr cmpi.l #MAGIC_MASK,d2
- beq.s BE_legit
-
- * Bus error was not legitimate, so report error and bomb out.
-
- jmp _bus_err
-
- * Legitimate bus error. Clear the DF (Data fault re-run) bit in the
- SSW
- * (Special Status Word) stored on the stack frame by the bus error.
- This
- * is horrendously complicated - refer to the 68EC030 User's Manual for
- a
- * full description of bus error handling.
-
- BE_legit bclr.b #0,(10,sp) ; Reset the DF bit in SSW
- moveq #-1,d2 ; Indicate bus error in d2
- rte
-
-
-
-